Object-oriented programming environments have become increasingly popular for the development of computer software. In an object-oriented programming environment, a program is divided into a number of software objects. Each object is a component, with its own code and data. One object cannot access another object except through the other object's variables and methods. That is, an object's internal variables and internal methods are not able to be accessed by other objects. A method of an object is a function providing the object with some functionality that can be accessed by a caller. Exposed methods are those that can be called by other objects; internal methods cannot. A variable of an object is the object's data, such that exposed variables are the data of an object that can be accessed by other objects, and internal (or, local) variables cannot be accessed by other objects.
In some object-oriented programming environments, such as the Component Object Model (COM), an object can have a context, such that there may be a number of contexts for a given computer program, with a number of objects within each context. A context generally specifies one or more common conditions for the objects within the context, one or more common aspects of the objects within the context, or one or more other commonalities of the objects within the context. Thus, by knowing a given object's context, facts regarding the object are known a priori, or a run-time. More formally, the context of an arbitrary set of objects specifies arbitrary invariants, including side effects when such objects are called from outside the context, on the arbitrary set of objects. These objects may be within the same or different process space. That is, where a computer program is defined as a process, it may have one or more threads of execution, where a thread of execution as used herein means the finest unit of execution that can be executed by a processor of a computer running the computer program. Thus, a process space refers to a given process, and the threads within that process.
Typically, objects within a given context usually only communicate with other objects within that context. However, some objects are what is referred to as agile. That is, they have no a priori context, and instead take on the context of their calling object. An agile object executes in the context of its calling object; the context of the calling object becomes the context of the agile object. However, there is not a common framework for describing the use and analysis of agile objects within the prior art. Furthermore, while uncommon, sometimes context-bound objects need to communicate with objects in other contexts. The prior art also generally does not provide for an efficient mechanism for such cross-context communication. For these and other reasons, there is a need for the present invention.